¿Cuáles son los modelos de ciclo de vida? ¿Qué es el ciclo de vida de desarrollo? ¿Qué es ciclo de vida y desarrollo de sistemas? ¿Cuáles son los modelos de ciclo de vida de un proyecto?

La aplicación de diferentes tecnologías concurre en la incorporación y puesta en marcha de sistemas de información, las principales son: Tecnologías de modelos de desarrollo; Tecnologías de gestión de proyectos para el control del proceso de selección, desarrollo, incorporación y operación de los sistemas; Tecnología de análisis y diseño de software. Cuando nos referimos a CICLO DE VIDA de una aplicación, estamos incluyendo las diferentes etapas por las que pasa esa aplicación durante su vida, desde su concepción hasta el abandono en su uso. En tal sentido, podemos conceptualizar en términos generales las siguientes etapas:

a) Definición:

Esta fase incluye el establecimiento de la visión externa del sistema, sus límites y alcances, la estimación del costo y esfuerzo requerido y la decisión de incorporarlo. Esta tarea es la de mayor impacto en el ciclo de vida y en el costo del sistema. Con la correcta ejecución se podrá: identificar las necesidades del usuario, determinar el alcance del proyecto, identificar alternativas de realización y realizar el cálculo de costo-beneficio y el plan global de las alternativas de solución. En esta etapa la participación del usuario es trascendente. El proceso de comunicación entre usuarios y analistas funcionales, y entre éstos y analistas técnicos resulta fundamental para comprender adecuadamente los requerimientos reales que debe cumplir el nuevo sistema de información.

b) Incorporación:

Incluye todas las actividades necesarias para su adquisición y/o construcción y puesta en marcha. Esta etapa es concomitante con el desarrollo del proyecto y se encuentra relacionado con el enfoque de ciclo de vida y la metodología de desarrollo que se emplee. La incorporación incluye las siguientes etapas o fases secuenciales: Organización y planeamiento; Ejecución y control (Análisis y diseño, Adquisición, construcción y prueba, Puesta en Marcha); Finalización. Un sistema puede ser un excelente desarrollo, pero inútil. Con la implantación se corona la tarea de desarrollo, verificando la correcta interpretación de los requerimientos del usuario y el buen desarrollo de las tareas posteriores.

c) Operaciones o utilización:

La utilización corresponde a la vida útil del sistema, durante la cual estará sometido a mantenimiento, es decir, ampliaciones y correcciones. El mantenimiento en particular cuando requiere aplicación de significativa cantidad de recursos, debe tratarse como un proyecto en sí mismo. Durante la etapa de operación del sistema una de las actividades distintivas es la de resolver la continuidad o el abandono.

d) Abandono:

Por último, el sistema es dejado de lado, siendo o no reemplazadas sus funcionalidades por otro. En caso de reemplazo, las actividades de transición correspondientes al abandono se deben considerar en el nuevo proyecto.

Podemos considerar como modelos básicos de desarrollo:

Por etapas (stagewise):

Este modelo considera que las actividades se secuencian una tras la otra, es decir no comienza la siguiente si no finalizó la anterior. La característica distintiva de este modelo es la secuencialidad. En este enfoque resulta sumamente fácil conceptualizar qué tareas atender en cada etapa. A la vez requiere la documentación previa y completa de los requerimientos y el usuario deja de tener contacto con el desarrollo en la etapa inicial y sólo lo recupera en la implementación. La mayor debilidad de este enfoque reside en que como sólo se puede “ver” el sistema cuando se completa el desarrollo, bien sea durante la capacitación como durante la puesta en marcha, recién en esas etapas avanzadas resulta posible detectar la necesidad de realizar una considerable cantidad de modificaciones y ampliaciones sobre lo ya construido para que el sistema cumpla sus fines. A mayor duración del desarrollo, resulta mayor el riesgo de necesidad de realizar el “mantenimiento previo a la operación”. La detección tardía de necesidades de modificación provoca un significativo aumento de costos y una demora en la implementación.

En cascada (waterfall):

Con el objetivo de evitar llegar al final del desarrollo sin tener una visión tal del sistema que pueda facilitar la detección en forma temprana de errores, Royce propone la retroalimentación en cada etapa con una fuerte participación de los usuarios e introduce la utilización de técnicas de “simulación temprana” del producto a lograr para que el usuario pueda “percibir” el producto final y así, determinarse ajustes antes de realizar el desarrollo. Es resumen, este sistema busca reducir riesgos, incorporando prototipos y retroalimentación.

Modelo evolutivo o “en espiral”:

El modelo espiral se basa en la idea de trabajar en una serie de versiones progresivas que agregan una mejora a la anterior, graficadas en cada ciclo de la espiral. El modelo se divide en cuatro cuadrantes por un eje vertical, que representa el costo acumulado del proyecto, y un eje horizontal, que representa el creciente nivel de compromiso del usuario y los desarrolladores con la solución alcanzada. Las cuatro actividades principales del modelo son representadas en cada uno de los cuadrantes: planificación de actividades para la siguiente fase; determinación de objetivos, alternativas y restricciones; análisis de alternativas, identificar y resolver riesgos; desarrollo de un prototipo de sistema o una versión parcial. En síntesis, busca reducción de riesgos de modificaciones, enfatizando prototipos e incorporando paralelismo y modularidad.

Modelos incrementales impulsados por un producto utilizable:

Para reducir el riesgo de necesidad de modificaciones previas a la implementación, las metodologías incrementales plantean dividir el sistema en subsistemas o módulos más pequeños definidos estrictamente para ser puestos en marcha independientemente y cubrir objetivos de negocio. En cierta forma puede conceptualizarse como una estrategia de implementación en la cual se concibe el producto final en su conjunto y su desarrollo se `secciona”, utilizando para su construcción alguno de los modelos vistos anteriormente. De esta forma los beneficios de utilizar el sistema se obtienen en etapas tempranas. En resumen, destacan la segmentación en módulos que ofrecen resultados implementables útiles para el negocio. La experiencia en la implementación de cada módulo se considera para ajustar el plan de los módulos siguientes. La ventaja que presenta la implementación superpuesta es la posibilidad de reducir el tiempo de implementación. Esto a riesgo de aumentar la posibilidad de tener que implementar ajustes en módulos ya avanzados en función de la experiencia de implementación.

Modelos Ágiles:

Ante demoras en las implementaciones, debido en gran medida a los “ajuste” de implementación, y de cambios en los requerimientos durante el plazo de desarrollo, se generó, a fines del siglo pasado, una tendencia hacia procesos de desarrollo que buscaban una fuerte interacción con el usuario y cierta inmediatez en la implementación, englobados bajo la denominación de “métodos ágiles”. Además, establece los siguientes principios (ver página 230). En líneas generales las metodologías ágiles proponen la realización de desarrollos cortos con alta participación del usuario, sin previa planificación de actividades más allá de una definición de alcances referencial y del tiempo, y son tendientes a una implementación inmediata. Han demostrado ser muy aptos para tareas de construcción de nuevas presentaciones de información, por ejemplo Sitios Web, y no tan efectivos para desarrollo de sistemas que requieran definiciones de múltiples estructuras de almacenamiento y complejos procesos de transformación. Entre ellas encontramos:

-RAD (Rapid Application Development):

ciclo de desarrollo iterativo con utilización extensiva de prototipos y alta participación del usuario

-Dynamic Systems Development Methods (DSDM):

evolución Del RAD.

-Extreme Programming (XP):

En XP la construcción del sistema se realiza en base a una “historia compartida” por usuarios y desarrolladores, que se va acotando para su desarrollo y prueba simultánea.

Sus principales críticos señalan que falta una definición explícita del producto a desarrollar, que se cubre con múltiples versiones, como si fueran nuevos requerimientos; que son versiones que son sucedidas por otras versiones, sin un claro objetivo a cumplir y con costos no justificados más que por la práctica realizada; que hay una imposibilidad de realizar un análisis de costos previstos y que hay dificultad de mantenimiento posterior debido a la falta de documentación.

Las metodologías son propuestas teóricas que incluyen procesos y herramientas para lograr el desarrollo de sistemas.

Entre los objetivos últimos de las metodologías podemos mencionar:

· Describir cómo hacer técnicamente para obtener el producto (proceso)

· Servir como elemento de comunicación (herramientas de documentación)

El proceso de comunicación en el momento de desarrollo es de gran trascendencia para:

· Que el analista interprete las necesidades del usuario, acordando la tarea a realizar (no significa "hacer todo lo que se solicite"), ya que puede haber pedidos fuera del alcance del sistema de desarrollo

· Lograr que los constructores interpreten las especificaciones, construyendo lo diseñado

La comunicación hacia el futuro es de gran trascendencia para que quienes se ocupen de la utilización, operación y mantenimiento del sistema, tengan la información suficiente para realizar sus tareas.

Los prototipos son representaciones del sistema en desarrollo para que el analista pueda representar su visión final a los ojos del usuario. Según su profundidad pueden limitarse la visión externa del sistema (imágenes de pantallas y listados) o simular su comportamiento incluyendo alguna funcionalidad de la aplicación, por ejemplo simulando el ingreso de datos.

Al presentar el prototipo al usuario se completa el ciclo de comunicación, validando los requerimientos y facilitando los ajustes que se detecten.

En la actualidad las metodologías dominantes son: la metodología de análisis y diseño estructurado y diseño orientado a objetos.

Esta metodología propone la construcción de un "modelo lógico" del sistema mediante la descomposición gradual de los requerimientos del negocio, para llegar a funciones elementales, sobre las cuales se detallan las especificaciones para la programación y se realizan los ajustes necesarios para la implementación física.

La descomposición del sistema facilita su comprensión por parte del usuario y desarrolladores como su construcción y mantenimiento.

El análisis se realiza desde dos visiones complementarias, la de datos y la de procesos.

· Los procesos, específicos para el sistema tratado, interactúan con los datos.

· Los datos se encuentran disponibles tanto para estos procesos, como para otros que los requieran, en un entorno de integración de múltiples aplicaciones.

Este enfoque permite, con una adecuada gestión de datos, facilitar la reutilización de datos, siendo este un objetivo perseguido para lograr una integración eficaz y efectiva de las aplicaciones.

La visión de los procesos se realiza partiendo desde un diagrama general representativo del sistema y avanzando en su descomposición, desde lo general a lo particular, utilizando como herramienta el diagrama de flujo de datos (DFD).

El DFD describe al sistema como una red de "procesos" conectados, mediante "flujos de datos", entre ellos mismos, con agentes externos (usuarios u otras aplicaciones) y con almacenamiento de información. Debido a que sigue una descomposición gradual, encontraremos diferentes niveles de DFD, donde:

· El nivel más alto se llama "Diagrama de contexto" o "DFD de nivel 0" y se limita a exponer la interacción entre el sistema y los agentes externos que actúan como fuentes y destinos de los datos. Muestra todo el sistema como un proceso único

· El DFD de nivel 1, desagrega los principales procesos del sistema modelado y su relación con los almacenamientos de información internos del sistema y los agentes externos señalados en el nivel 0.

· Así sucesivamente cada proceso se desarrolla en el nivel siguiente, respetando la relación con agentes externos y almacenes de información, y agregando los almacenes internos de ese nivel.

· Finalmente, cuando se llega al último nivel de descomposición, el comportamiento del proceso se detalla para su decodificación fuera del DFD, utilizando principalmente los siguientes artefactos específicos:

-Lenguaje estructurado

-Tablas de decisión

-Árboles de decisión

La visión desde los datos consiste en la formulación de la estructura lógica de datos. Consiste en agrupar los datos requeridos por el sistema en entidades, utilizando la técnica de normalización detallada en el capítulo 10.

La técnica de normalización parte desde la identificación de todos los elementos de la base, analiza las relaciones subyacentes entre ellos y permite determinar la mejor forma de organizar los datos en tablas, en función de esas relaciones.

Parte de la idea de que todos los datos pueden resumirse a relaciones simples entre tablas para representar al sistema objeto, dando mayor facilidad para responder preguntas, que pueden responderse con los elementos ya contenidos, como para responder nuevos requisitos que necesitan el agregado de elementos adicionales.

El proceso de normalización garantiza que la estructura de datos así determinada es la que mejor representa la relación subyacente a los datos requeridos por el sistema. También asegura el mantenimiento posterior como las ampliaciones y la integración con otros sistemas, que seguramente requerirán el agregado de nuevos datos o tablas con nuevos datos, y esto no va a desnaturalizar la estructura lógica definida.

Por lo tanto, la estructura lógica de datos debería ser considerada como la base sobre la cual no solo se construirá una

aplicación en particular, sino también, la base sobre la cual se asientan las modificaciones a esa aplicación y los futuros desarrollos e integraciones con otras aplicaciones.

Ambas visiones son complementarias (DFD y DER)

Luego de consensuar el diseño lógico, se realiza su implementación física. Para esta implementación se tienen en cuenta las restricciones tecnológicas (básicamente capacidad de almacenamiento y tiempo de respuesta)

1-Agrupación genérica de datos. Formación preliminar de entidades.

Se agrupan los elementos en “entidades preliminares” (registros tentativos), en función de sus características obvias.

2-Normalización según la primera forma: Eliminación de grupos repetitivos

Se identifican aquellos grupos de elementos que se repiten para un mismo registro, formando con ellos un registro independiente, vinculado con el originante por medio de su identificador.

“una tabla está en primera forma normal (1FN) si no contiene grupos repetitivos de elementos para el mismo registro” 3-Normalización según la segunda forma. Eliminación de dependencias funcionales parciales con el identificador. Se abren nuevas entidades para los atributos que no tengan dependencia funcional con el identificador completo.

“una tabla está en segunda forma normal (2FN) si todos sus elementos presentan dependencia funcional con el identificador completo.

4-Normalización según la tercera forma. Eliminación de dependencias funcionales transitivas con el identificador Consiste en abrir nuevas entidades para los elementos que no tengan dependencia funcional directa con el identificador, es decir, que tengan dependencia funcional con otro elemento y este con el identificador.

“una tabla está en tercera forma normal (3FN) si todos sus elementos presentan dependencia funcional directa con el identificador completo”

A diferencia de los métodos estructurados, que separan datos de procesos, el enfoque de análisis y diseño orientados a objetos (ADOO) une datos y procesos en artefactos denominados “objetos”.

Un objeto puede ser un lugar, una persona o una cosa relevante para el sistema, por ejemplo un cliente, una factura, un empleado, un proveedor.

Las actividades de desarrollo se centran en los objetos. El software se organiza a partir de los elementos que existen en el dominio del problema.

El análisis y diseño orientado tiene por objetivo la construcción de un modelo que interprete la complejidad subyacente en el sistema objeto y la determinación de su equivalente lógico, no la aplicación de herramientas de programación orientadas a objetos.

La implementación física posterior dependerá de los lenguajes y bases de datos utilizados.

En los términos ADDO un objeto es todo conjunto cohesionado (adherido fuertemente, atraído internamente), integrado por dos componentes esenciales:

Atributos (datos organizados)

Servicios (referentes lógicos de los procesos de transformación, operaciones, los cuales reciben y entregan información al exterior del objeto por medio de parámetros)

Métodos (forma en que se implementan los servicios; un mismo servicio puede implementarse con diferentes métodos, dependiendo de la tecnología que se utilice)

El armado conjunto de atributos, servicios y métodos se denomina “encapsulado”

El encapsulado provoca “ocultamiento de información”, haciendo visibles y accesibles los datos sólo mediante los servicios implementados, así:

Protege los datos del uso arbitrario

Oculta los detalles de la implantación interna a los usuarios de un objeto, por lo que los usuarios conocen los servicios que puede solicitar del objeto, pero desconocen los detalles de cómo se llevan a cabo.

Al separar el comportamiento del objeto de su implantación, permite la modificación de ésta sin que se tengan

que modificar las aplicaciones que lo utilizan, en la medida que se mantengan los servicios.

El “objeto” factura puede tener como servicios, entre otros, los siguientes:

Informar nombre del cliente destinatario de la factura

Informar el importe total.

Un objeto contiene una estructura de datos y comportamientos que lo caracterizan.

Solo se accede a él por los servicios establecidos.

Los distintos objetos se comunican por “mensajes”. Un mensaje solicita un servicio que ejecute el método apropiado y, en su caso, realice una modificación de datos y/o produzca una respuesta. El mensaje que constituye contiene el nombre del objeto, el nombre del servicio y, según corresponda, un grupo de parámetros.

De esta forma se pueden “crear” aplicaciones nuevas combinando, mediante mensajes, objetos existentes, integrando en objetos y construyendo los objetos no existentes. Así mismo un objeto puede estar compuesto por otros objetos, formando un objeto complejo.

Los objetos tienen las siguientes características:

1)) Clasificación

Una clase es un grupo de objetos que tiene atributos y comportamientos similares.

2)) Identidad o instanciación

Objetos con iguales atributos y servicios son distinguibles entre sí, debido a que tienen una característica distintiva de “identidad”.

Por ejemplo, dentro del objeto “factura”, el número de documento ley de “identidad”. Por lo tanto, un objeto tiene una “instancia” única de una clase, que posee su propio valor para cada uno de los atributos, pero comparte los nombres de los atributos y las operaciones del resto de la clase.

3)) Jerarquía y herencia

Las clases se encuentran relacionadas jerárquicamente, y comparten atributos y servicios tomando como base esa relación jerárquica.

Una clase puede incluir sub-clases de nivel jerárquico inferior.

Esta es una característica fundamental y trascendente, ya que permite que conociendo el comportamiento de la “clase” se sabe que la subclase tiene el mismo comportamiento, más otros comportamientos adicionales específicos de ella.

4)) Polimorfismo

Un mismo servicio puede comportarse de manera diferente en distintas instancias de una misma clase, por aplicación de un método diferente.

Así un usuario no necesita conocer el método aplicado para una operación o servicio, y, a la vez, se pueden agregar instancias nuevas a una clase en la medida en que el objeto de la instancia tenga el servicio con su método.

Durante el proceso de diseño se realiza la “segmentación”, esto es la asignación de responsabilidades a una clase de objetos, para lo que se requiere.

Se “centralizan” todas las funciones que correspondan al mismo objeto, es decir, utilizan los mismos datos y realizan la misma transformación, generando economías en el desarrollo y el mantenimiento al garantizar la rentabilidad.

Existen muchas herramientas utilizadas en metodologías orientadas a objetos, algunas de ellas superpuestas. Esto hace que los artefactos correspondientes a las metodologías orientadas a objetos resulten complejos y requieran una mayor formación para su interpretación que los artefactos de diseño estructurado.

Para lograr unificar estas herramientas se construyó un lenguaje unificado de modelado, conocido como UML (unified Modeling Language)

Si bien estos sistemas ofrecen una funcionalidad estándar flexibilizada en forma paramétrica, es decir, es habitual que no cumplan con todos los requerimientos funcionales y de integración con el resto de los sistemas de la organización.

Si fuera necesario cumplir con requerimientos no cubiertos por el paquete ya parametrizado, nos encontraríamos ante la necesidad de modificar el producto, construir agregados por fuera del producto, construir agregados por fuera del producto o complementar el producto con tareas manuales.

Por lo tanto los requerimientos no cubiertos por el paquete pueden dar lugar a:

Incorporar el paquete, sin esos requerimientos

Realizar adecuaciones y desarrollos complementarios para cumplir con esos requerimientos.

Alguna situación intermedia.

La detección y explicitación de la brecha entre requerimientos y disponibilidades debe realizarse en forma temprana, antes de la adquisición misma del paquete, ya que la cobertura de ella puede generar costos tales que, de haberlos conocido anteriormente, podrían haber cambiado la decisión tomada, tanto hacia la compra de otro paquete como un desarrollo a medida.

Tanto las adecuaciones como la implementación del paquete en sí mismo, requieren un enfoque de ciclo de vida y metodológico.